寫Log現在己經是開發人員的基本功了，每個開發人員或多或少都會一些留下記錄的方法：有人會直接顯示在Console上，有人會傳到檔案裡，更高階的就會有一個管理工具去分析或提前準備一些東西（SRE很有趣，有興趣可以研究看看）。
Log某個層面來看，其實也是一種資料儲存，留下大量的資料待分析或處理，所以他是會相互影響的：如果寫得太多可能產生太多資料造成空間上的浪費，寫得太少跟沒有寫一樣。那怎麼寫Log才是恰如其份呢？

Log Level

就像Issue tracker一樣，如果每個問題都是緊急且重要，那跟沒有分類的意思是一樣的。無論是否有用Log Tools，在寫Log的時候應該標示分類，至少要分成以下三種：

• Info : 記錄類，大部份的情況下可以忽略的Log，通常就是記錄一些資料進出或處理的記錄。
• Warning：可能造成使用者無法完成問題的Log，但系統仍會繼續運行。例如說使用者傳入了，或收到了預期裡不會出現的資料。這類的資料如果開始密集的出現時，就應該要馬上處理。
• Fatal：任何會造成系統或使用者的權益可能造成損害，並且無法進行時寫的Log，例如呼叫的API出現了500，Exception頻繁的出現...等等。出現時基本上系統己經紅燈了，應該馬上處理。

當然還有其他的分類方法可以視情況使用，但重點是要視情況分類，不要全部都寫成同一類。

5W1H

寫Log時請不要只寫著

    try
    {
    }
    catch (Exception ex)
    {
        logger.Error(ex, "Something bad happened");
    }

這對追查問題沒有幫助，想看看如果有一天在系統裡看到這種Log，要怎麼追問題？
請留下發生問題的地點，參數，做什麼事情的時候發生的，為什麼會發生...等資訊到Log tracker裡，這樣才知道怎麼往下追問題。

找個好一點的系統來讀Log

時代不斷在進步，可以的話花一點點錢或時間投資在Log monitoring system吧！圖表的目的不是創作炫炮的視覺感受，而是建立起一個基本的baseline，這樣才知道系統對於問題的忍受程度在多少？當超過多少時需要注意，也可以在大量的資料中快速的找到需要的目標。這些都是風險控管的一部份，如果公司有意導入SRE，這也是相關的基礎工程之一。

Ref:https://www.dnsstuff.com/log-management-tools

寫Log的"模式"

如果程式的安排妥當，寫Log的方法就變得更靈活。在程式適當的位置安插Log，這樣可以同時減少寫Log的程式碼出現，同時也擴大Log的覆蓋範圍，有很多的選擇，例如AOP(Aspect-oriented programming)或Decoration Pattern都是很適合的做法。

@Before("deposit() && withdraw()")
public void writeLogBeforeTransaction() {
 
  _logger.Info("User is going to transact money.");
}

AOP絕對值得程式設計師投入時間去研究，試著找一套AOP工具改寫程式看看，會讓你的程式看起來非常不一樣。